Can t believe its almost 7 years since my first sponsored upload of Dibbler to Debian archive. I did it cause upstream promised to maintain it and fix any bugs submitted by Debian users. Unfortunately after 3-4 years he stopped to do it. Well since I was the sponsor of it, then I should feel responsible for these packages after him. It s quite hard to do it, cause I m not using these packages at all Anyway, I finally found some time and reviewed them. It wasn t easy cause in the meantime whole build process totally changed. To whom it may concern: Dibbler is an IPv6 DHCP client, relay and server. I ve just uploaded the newest upstream version. Changelog follows: dibbler (0.8.1-1) unstable; urgency=low * ACK previous NMUes thanks!
* New upstream version (Closes: #629685)
uses correct example adsress pool in examples (Closes: #544323)
corrects scope of stateless in manpage (Closes: #615165)
* Fix pending l10n issues. Debconf translations:
Danish courtesy of Joe Hansen (Closes: #597767)
Dutch courtesy of Jeroen Schot (Closes: #632628)
* Fixes handling of children processes using resolvconf (Closes: #627317)
* Doesn t conflict with other resolver configuration daemons (Closes: #627786)
* Correctly handles multiselect values from debconf (Closes: #629681)
* Debianized almost from scratch, uses new source format.
* New Standards-Version (no changes needed). Bartosz Fenski <fenio> Fri, 27 Jan 2012 14:37:13 +0100 Yep, it fixes 8 bugs, and brings the newest upstream version with huge number of new features to Debian. Enjoy!

The increasing storm of localization NMUs and uploads, related to debconf translations, has an interesting effect: some teams are now incredibly active at pushing translations for their language towards the magic 100%. So, after Danish (effort lead by Joe Hansen) and Dutch (effort lead by Jeroen Schot) which I already mentioned, it seems that the Italian localization team started engines and is now taking off. It will be interesting to watch these teams competing (in a friendly way) to climb in statistics over next months..:-) So, if you're Italian (or speak it well) and want to help, please join the Italian l10n mailing list (debian-l10n-italian on lists.debian.org. If you're Danish or Dutch and want to stay ahread the two others, please joind debian-l10n-danish or debian-l10n-dutch. PS: why did I write "Zou" in this post's title? Because this is a common French interjection for "Whoooosh" and because this is part of the nickname of the tireless and incredibly active, in many places, Francesca Ciceri, aka MadameZou, who's is doing so much for Italian localization (and many other areas in Debian such as the publicity and web team). And that really deserves some lights, trumpets, etc.

This article could become one of my recurring "let's make noise about translators work" articles. You've been warned. In Squeeze, a few languages reached full completion of debconf strings, those "questions" that are asked during packages installation or upgrades. This can be followed here (for unstable: we don't have an online status page for testing).. Many of you, particularly those who aren't bored at reading me, know that I like pushing this friendly "competition" as a good way to encourage progress in localization of that part of Debian. As of now, we have really good and active teams that are able to maintain a great completion in this. Several of them are likely to reach full 100% completion for wheezy. Let's look at the current status:

• Seven languages are currently the best candidates for full completion: Czech, Spanish, Portuguese, Swedish, Russian, German and French. They will definitely reach 100% in unstable and I'm tracking the status in testing, which is currently excellent.
• The status for Japanese is a bit unclear to me. Though the completion is quite high, I don't witness a constant effort to bring what's incomplete to the complete status. So, I unfortunately doubt it can make it to 100% (Japanese translators, you know what to do to prove me wrong...)
• Vietnamese which is next in the ranking has a specific situation. Its main (by far) contributor, Clytie Siddall (who is a very well known figure in the l10n community for free software as she contributed to Vietnamese l10n of many end-user software), cannot currently do the highly dedicated work she was doing, because real life sucks. There have been tentatives by the local community in Vietname to take this effort over, but they're probably more focused on end-user software than Debian work.
• Dutch and Danish are the best suspects for joining the 100%-fighters club. Both now have at least one very very motivated contributor who's "jumping" on each and any pending l10n work. So, yes, Jeroen Schot and Joe "Dalton" Hansen, you can make it!
• Effort for Italian is not as constant as it could be. It is maybe missing a noisy and hardworking "leader". Still, I know that the team is very active in other areas of localization such as the DDTP (where Italian is leading) so, maybe one person could diverge his her attention for debconf work..:-)
• A few next languages see a more hectic activity: Galician, Finnish and Basque used to have one very active contributor, but recent activity is much much lower.
• Brazilian Portuguese sees some effort but the situation is similar to Italian, here. The pt_BR team is more focused on the DDTP (and does well in this). It might only need a motivated volunteer, but 100% is quite far and the effort would be focused on wheezy+1
• Slovak is indeed one of the good candidates for "could be 100% some day". Progress is currently quite regular but Slavko is starting from very far away and it will take time. Keep going on!
• Other in the ranking are really mostly stalled, so if you language is among them....then, you known what to do!

I hope this maybe gave you the idea of joining these efforts. Please pop up on one of the i18n mailing lists if you're interested, and if you don't know where to start, then debian-i18n< is what you're looking for. See you soon!

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.

Year	Count	Names
1999	4	Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000	4	Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001	4	Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002	3	Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003	4	Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004	3	Martin Michlmayr, Gergely Nagy, Branden Robinson
2005	6	Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006	7	Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007	8	Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008	3	Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009	2	Stefano Zacchiroli, Steve McIntyre
2010	4	Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011	1	Stefano Zacchiroli (no vote yet)

Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

Even though I do not understand the whole European campaign-period concept, I kept my mouth shut even though it was at odds with trying to answer every question, no matter how stupid. I give props to Jeroen for his efforts in question-answering that year, even though the electorate obviously never cares about that. I wanted to answer all questions directed to all candidates (excluding replies for the same reason that I only responded on-list to questions directed explicitly at me), but did not. Quite a bit of the encouragement I have received after the fact has been from people who are not DDs. I find this strange since most of what I have said has been about the enfranchisement of DDs, and nothing about non-DDs. I could speculate about why this might be the case, but I will refrain. We now return you to your regular program.

Percentage of Debian Developers preferring new elections to having AJ as DPL in March/April: 17.3%. Percentage of Debian Developers preferring new elections to having AJ as DPL in October: 14.8% That's right. contrary to what one would expect from merely reading the mailinglists, an even larger majority now finds AJ acceptable as DPL. This does not render the objections of the couple dozen DDs irrelevant though, diversity is a great good. However, diversity can easily escalate to divisiveness when different opinions or more accurately the ways they are voiced start to severely hinder activity by others. I myself have been quite demotived by the whole discussion, as has happened to me multiple times before. We Developers do not seem to be able to have constructive discussion without getting extremely heated up. I believe that this inability to hold discussions about tricky subjects is way more hurting the project than any of the "tricky subjects" themselves. Actually, the tidbit in my DPL-elections platform about Communication among Debian contributors is still equally relevant. Several potential improvements have been proposed in the past, including debating by wiki, debating inside a smaller taskforce, or even having a representative democracy. Let's explore the representative democracy principle a bit further: In general, I consider making decisions by GR (or to draw a parallel to country government, referendum) bad: A majority of voters doesn't have adequate and balanced information to make a reasonable decision, that takes doing quite some research. Instead, any discussion (vote winning?) is going to be significantly depending on emotions. Take the voting-down of the European constitution by France and the Netherlands: Hardly anyone has adequate information to really make a tradeoff, still quite a number of people voted, and supposedly one of most prevalent considerations was fear of this "Europe" thingy. Therefore, I'd really prefer that issues like firmware are dealt with by smallish team of people who really can look into the issue well, consider all arguments either way, and make a decision. As with every decision in Debian, it can be overturned by GR, but still. Note that we don't need any consitutional change for this, the DPL already has the power to delegate a person or group of people to make some decision nobody else specifically is responsible for already. A complicating factor is though that it's hard to compose such a taskforce that will have the project's support once a discussion is 'heated up'. In other news, rumour has it that -private has blown up today. I'm so looking forward to opening that mailfolder.

Compare:

• gNewSense's bug#1
• Ubuntu's bug#1

It's done: today I heard about the last (passing) mark for the last course I need to follow for my Master in Applied Computing Science, at Utrecht University: a paper about RFID security and privacy as part of the Cryptography course. Besides some small paper still due for (ahum) my Bachelor, the only thing left is my thesis with associated research. Today I got an invitation for my first working day at ORTEC in Gouda, next month, where I'll be doing research (and implementation) on some exciting new route planning algorithms. It'll require some getting used to it, five days a week, 8 hours a day, for the rest of the year. One of the biggest challenges will be getting up in time every single day, but I'm sure I'll be fine with that eventually. I have confidence that the interesting research will make up for it completely! Already this Friday I'll be going to FOSDEM with Thijs, partly by train, and partly hitchhiking a ride from Joost. Too bad my laptop practically died... But reading mail etc. not the most important thing in FOSDEM, you can do that at home too I hope to meet yet again a whole lot of old and new Debian people over there. For the first time in 3 years no talk from me, other duties took too much time lately. I'll need to discover how much time I'll be able to spend on Debian as a full-time employee, but I think it'll make it easier for me to divide my time: I really missed doing Debian stuff from time to time, and I need to fix up a number of neglected areas real soon now. Good night!

June is the last month before summer holidays, and at this phase in my study, courses take a lot of time: practical assignments, seminars to give, multiple exams. And mid-June, I'll be attending DebConf in Edinburgh, including delivering a talk about Mole, the subject of my Google Summer of Code project. In the period of April/May students participating in the Summer of Code project had the time to get more familiar with the project they were going to work for. Because I'm already somewhat familiar with Debian, I opted to organize an Etch release party together with some friends, because, well, what better way is there to get to know the community? During the past two weeks I've been really starting with the project. I updated the wiki page, added a new development page where I keep track of my work listing the subtasks I'm working on and their status. The first month will be mostly work on the internals, but starting with the second month I'll also be working on the web interface, meaning that there should be some stuff to show off. At the moment I'm refactoring some bits of Mole that are currently implemented in a hacky way, in order to make it all as extensible as it should be. This includes defining a config file format for mole tables, so that it's no longer necessary to modify the python code for new tables. It also involves some better way of stacking tables to each other, so that the package file extraction code can be moved away from the core of mole into a separate worker to keep mole itself pure and simple and generally applicable. I'll post irregular updates to my blog. I'm looking forward to seeing a lot of you again this Thursday, when I'll arrive in EDI!

Yesterday I had one of the more stressful and eventful 40 minutes of my life... events basicly initiated by the fact that I arrived at Schiphol airport 40 minutes before my plane was scheduled to take off. The first thing I noticed was that the queue for security extended beyond the check-in desks next to it, so just that bit would probably take more than fourty minutes. Oops. What are all those people doing flying out on friday noons? Second thing I couldn't help to notice is that the check-in desk was actually already closed, double-oops. Well, the lady that was sitting there anyone concluded after a phonecall that my bag was fine as hand luggage and so that I could still make it. She also queue-jumped me straight to the security X-ray machine and ordered me to run from there on. Well, not so fast, running through security isn't appreciated. Actually, since I planned to check-in this bag, I kind of violated this whole anti-liquor^Wliquid silliness with no less than 7 items. The guy that unpacked my luggage let me keep my lenses fluid, and forgot to notice 3 of the items, so damage was limited, and I proceeded with my explosives, I mean, toothpaste and such, to the gate. In my hurry to run to the gate, I put my boarding pass in my pocket... and upon arrival at the gate, I noticed my boarding pass was gone, so I went ask some lady at the desk there about it... and overheard the guy next to her, who was on the phone, mention my last name. "Someone found your passport". Turns out they also had my boarding pass, but I appreciated knowing where my passport was anyway, since obviously I didn't have it on me anymore either. So within a minute I was running off again to a different gate to pick up those two sort-of-important items. You'd say that after having once seen my plane taxi away from an empty gate upon returning there from picking up my boarding pass from lost&found for the second time that very morning would've taught me a lesson... But apparantly not. Back at the gate I was getting past the boarding pass checkpoint, and the person over there saw my pass, and said "Hey, so you're that guy that a bit ago lost this and that at the security checkpoint?" Since that happened at the other end of the airport, gossip must be going pretty fast at Schiphol... At least I've never showed up at the airport at the wrong date (unlike two of my friends I'm meeting over here managed to do each independently)... Yet.

Here comes the new 4096 bit RSA key, replacing the old (2002) 8CA99047 1024 bit DSA key:

pub  4096R/29C0FFEE 2009-05-18
  Key fingerprint = 9590 8AA6 E4F7 BAA7 8BD6  C148 F1A6 9BE4 29C0 FFEE
uid  Obey Arthur Liu <arthur@milliways.fr>
uid  Obey Arthur Liu <obey.liu@ensimag.imag.fr>
uid  Obey Arthur Liu <graffit@graffit.net>
uid  Obey Arthur Liu <obey.liu@lzb.fr>
uid  Obey Arthur Liu <arthur.randolph@gmail.com>
sub  4096R/15D7FD9B 2009-05-18

In other news, I found a great flatshare on Riedmattstrasse in Kreis 3 in Z rich with a fellow Google summer intern. Thanks to all (Jeroen, Martin, Jaroslavs, Giacomo..) who gave me pointers about finding accomodation in Z rich. I m looking forward to a great summer there. * It did involve generating about 40 millions gpg keys on a few tr s badass computing clusters UPDATE: Come on guys. Of course I followed basic key management rules. The clusters which generated the actual final keys were under my direct control and the particular slice which generated this published key is on my desk.

So, the call for vote on the “Project membership procedures” GR was sent. Since I took part in the discussions that lead to that GR, I feel obliged to explain my point of view. What this GR isn’t about
This GR isn’t about the merits of Joerg Jaspert’s proposal. I personally don’t think that the changes he wants to implement are what we need in Debian, but even if I fully agreed with those changes, I would still disagree with the process that led to those changes. Also, this GR isn’t about Joerg Jaspert himself. I deeply respect him and his awesome work for Debian. And I’m sure that this vote could have been triggered by decisions announced by someone else. What this GR is about
I think that the question we are asked to vote on is:

Some people in Debian have a special role, and special privileges. Does it allow them to change important aspects of our project, without the approval of all the other developers?

Or, put differently:

Where is our limit between Doocracy and Democracy?

I’m all for listening to developers who contribute(d) a lot. I think that most people, when skimming through posts in a big thread on -devel@, will look for posts from people who did a lot of work for Debian, or who usually post interesting ideas. However, that doesn’t mean that those people should feel empowered to decide changes to important parts of our project, without first discussing those changes with all other developers, and making sure that those changes are consensual. So, I hope that we will send a clear message that says: you are very welcome to propose changes, but please make sure that they are properly discussed within the developers before they are implemented. Joerg’s initial mail on d-d-a, with a few s/decision/proposal/, and a final question phrased like “Any comments? Suggestions? Other ideas?”, could have been the start of an interesting discussion about how we can integrate non-developing contributors in Debian. And if too many developers disagreed, we could have had an opinion poll (it would be great to have an infrastructure for running polls inside Debian, like what Jeroen did three times a long time ago), or even a GR, like we did for Debian Maintainers. For this actual vote, there are two similar options on the ballot (choices 1 and 2, respectively “amendment text A” and the original text on the vote page). I proposed this amendement (choice 1) because the original text is unclear, and mixes several different questions, forcing voters to answer several (secondary) questions at once, like:

• Do we recognize that there are contributors that can’t become members of the project currently, and that should?
• Do we want to thank DAM for bringing this up? (implicit question or not: … now that we are trying to release?)
• Do we want DAM to work on a new proposal?

The amendment aims at going straight to the point. And yes, it is only asking the DAMs, but if the developers ask the DAMs not to do something, and the DAMs do it anyway, we clearly have a bigger problem. I believe that the way those decisions were announced was a mistake (that unfortunately none of the people involved have been willing to admit), not that the DAMs are trying to take-over Debian, so there’s no need for a stronger wording.

Even though I ve dealt with IPv6 for almost a decade, have delivered presentations, and given multi-day courses on IPv6 security aspects, I ve never actually added IPv6 to my own server/home network infrastructure because it seemed that Linux and/or Debian just weren t ready for it. This seems to have changed (although there are still a number of problems) and in less than a day, I put a few of my machines online. In the following, I d like to share with you how I did it.

Kernel versions and stateful connection tracking Unfortunately, I have to start off with some bad news: even though Debian etch, our current stable release, which uses a Linux kernel version 2.6.18, speaks IPv6, I cannot recommend it for deployment, as the 2.6.18 kernel does not support proper stateful connection tracking for IPv6, and thus makes it impossible to firewall hosts in a sensible manner (I always add local packet filters to all my hosts, and if only to guard against the situation when a user installs a malicious programme to listen on a high port). Of course, it is possible to configure a packet filter statelessly in an acceptable manner once you know the use case, so do with this information what you wish; I prefer to stay general for now. For me, a remedy is almost around the corner: the 2.6.24 kernel seems to support stateful connection tracking for IPv6, and it s even available for etch as it will be included in the upcoming etch-and-a-half release. I simply ended up using the kernel packages pre-release, and so far have not had a problem with it. To do so, add the following line to your /etc/apt/sources.list, making sure to use a close archive mirror:

deb http://ftp.xx.debian.org/debian etch-proposed-updates main

I then just upgraded the system and pulled in all proposed updates. As that may have let in software that won t be part of etch-and-a-half, or even lenny, you may want to pin the archive and only upgrade the kernel packages, by adding to /etc/apt/preferences (replacing amd64 with your architecture):

Package: *
Pin: release a=proposed-updates
Pin-Priority: -1
Package: linux-image-2.6.24-etchnhalf.1-amd64
Pin: release a=proposed-updates
Pin-Priority: 600

Alternatively, you could use the 2.6.24 linux kernel packages on backports.org.

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a dom0 on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 dom0 is reported to work, however.

Configuring the packet filter The first thing I did was to configure the packet filter on each host appropriately. Unfortunately, this is harder than it should be, because to quote one of the netfilter developers when ip6tables was conceived, someone had a big bad brainfart : rather than adding IPv6 rules to your existing iptables ruleset, you have to create a new ruleset, duplicate all chains, networks, hosts, and individual rules, and maintain the two in parallel. Even though there are efforts of unification on the way, I speculate it ll take another couple of years until PF_INET6 will be fused into PF_INET and one will be able to do sensible cross-address-family packet filtering with Linux. Since I ve recently started to look (again) at pyroman, maybe the most logical way forward would be to extend it to write both, IPv4 and IPv6 rulesets from its knowledge about the hosts and networks you configured. Anyway, we want to get stuff working now! Thus, let s configure ourselves a packet filter. (Almost) all IPv6-related filtering must be configured via ip6tables (read on further down about IPv6 in IPv4 tunneling, the reason I said almost ). The following is a simple default ruleset to start with, which I put into /etc/network/ip6tables to load with ip6tables-restore:

*filter
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT ACCEPT [0:0]
:in-new - [0:0]
### INPUT chain
# allow all loopback traffic
-A INPUT -i lo -j ACCEPT
# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT
# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT
# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new
# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT
# log everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "
### OUTPUT chain
# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT
# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT
### FORWARD chain
# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT
# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT
COMMIT

Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking. The ruleset should be fairly obvious, but you might wonder about my use of REJECT and allowing all ICMP after all, you ve heard for the past 30 years that ICMP is a bad hacker protocol , and Internet security is no domain for being nice to people, so to prevent any information disclosure, you should DROP connections, not let people know that they re simply not allowed. Well, to hell with all that! I don t see a single reason or attack vector that is foiled by DROP or disallowing ICMP. In fact, it s just security by obscurity, and might inconvenient at the same time. ICMP is also much more important with IPv6 than with IPv4 (it replaces ARP, for instance), and it s actually useful to be able to ping hosts, or get back informational messages on why something failed. Finally, rejecting traffic rather than dropping it doesn t suggest to a hacker that something s hidden here. Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!

Getting connected If you already have an IPv6 address, you re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net. If you are reading up to here, I assume you are connected to the Net with IPv4. There are two ways for you to move towards IPv6: 6to4 or by way of a tunnel provider. A Kiwi website explains how to setting up 6to4 connectivity, and thus I will concentrate only on the tunnel approach. Even though everyone can set up 6to4 in a breeze without any accounts or waiting, there are a number of security considerations, it s pretty ugly to debug (due in part to asymmetric routing), and makes your life unnecessarily difficult when all you have is a dynamic IP that changes from time to time. If you are stuck behind a NAT gateway, you cannot use 6to4 either. Thus, I prefer the tunnel approach. With the tunnel approach, IPv6 packets are wrapped up in IPv4 packets on your host, and sent to the IPv4 address of your tunnel provider, who has native IPv6 connectivity. The tunnel provider unwraps your packet and shoves the contained IPv6 packet onto the backbone. The IPv6 address you used as source address is routed to the tunnel provider, so any replies arrive at their machines, where they re again wrapped into IPv4 packets and sent to your (publicly-accessible) IPv4 address. Those IPv4 packets specify payload type 41 ( ipv6 ), which is why we need those -p ipv6 -j ACCEPT rules in the iptables ruleset. There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts. Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:

• static tunnels, for those with static IPs,
• heartbeat tunnels, for those with dynamic IPs, and
• AYIYA tunnels, for those behind NAT gateways.

Each of these tunnels have advantages and disadvantages, as everything does: the first two types of tunnels use IP protocol 41 packets to encapsulate the IPv6 packets. As such, there are security considerations involving the impersonation by spoofing, and all upstream firewalls must let protocol 41 pass. AYIYA addresses these problems by using signed packets, but that solution comes with extra computation overhead and smaller MTUs. I suggest to use the first type of tunnel that fits your situation. Debian s aiccu package can take care of heartbeat and AYIYA tunnels for you, and it can even set up static ones. During registration, you will also need to choose a PoP , which stands for Point of Presence . If your country only has a single PoP, that s the one you will end up using (unless you have a good reason for another one), but if there are more options, I strongly suggest that you go through the list of PoPs and select the one with the best roundtrip time and lowest latency from your location! Note that you must answer ping requests (ICMP echo-request) from the PoP you chose, or else the tunnel will not be created. Once your tunnel request gets approved, you ll get a /64 prefix, in which you only use two addresses: the PoP will configure the :1 address and you need to configure your host to use the :2 address on the tunnel interface. You ll also be told the IPv4 address of your PoP endpoint . Joey Hess taught me that aiccu can set up the interface for you, using the data it queries from the SixXS registration (TIC) server. I tried it, and it works. However, I prefer the pure ifupdown approach, as it makes things explicit and allows me to use the hooks for stuff like loading the packet filter. So in my /etc/network/interfaces, you can find:

auto sixxs
iface sixxs inet6 v4tunnel
  endpoint 194.1.163.40
  address 2001:41e0:ff00:3b::2
  netmask 64
  gateway 2001:41e0:ff00:3b::1
  ttl 64
  pre-up ip6tables-restore < /etc/network/ip6tables
  up ip link set mtu 1480 dev $IFACE
  up invoke-rc.d aiccu start
  down invoke-rc.d aiccu stop

Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity. Also set ipv6_interface sixxs in /etc/aiccu.conf, if you are using aiccu, or else aiccu will bring up a duplicate/additional interface. If you tell it to use the same interface, it will actually execute all the same commands (which will fail), but won t report any errors. A future version will have a switch to prevent it from configuring the interface. Unfortunately, this will probably not work. The reason is that your regular IP packet filter (iptables, without the 6) doesn t let those encapsulating IPv4 packets pass, unless we tell it to; we probably want to do this early on in the chain, and also limit it to our tunnel peer, so:

iptables -I INPUT -p ipv6 -s 194.1.163.40/32 -j ACCEPT

For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn t work, you have an upstream packet filter that needs some of those holes poked. Good luck. In most situations, the FORWARD chain does not get such a rule, since the tunnel terminates at the gateway, which routes to a native IPv6 network, or another tunnel. Allowing tunnels through a gateway is almost always a bad thing, as it would allow undetected and untraceable traffic from compromised boxes in the local network. The OUTPUT chain also does not need such a rule, if you have configured stateful filtering properly. Now bring up the interface and verify the connection:

# ifup sixxs
# ping6 -nc1 2001:41e0:ff00:3b::1
PING 2001:41e0:ff00:3b::1(2001:41e0:ff00:3b::1) 56 data bytes
64 bytes from 2001:41e0:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]

Welcome to the Internet of the future!

Setting up an IPv6-capable gateway Your IPv6 connection works, but it s limited to a single address, and you do not get to specify the reverse DNS PTR record for it. Since the concept of NAT is mostly absent from IPv6 (thanks! thanks! thanks!), you will not be able to connect any other hosts to the IPv6 network. If your local network has a few hosts behind a gateway, you will need to request a subnet from SixXS and configure your gateway (which has the tunnel connection) appropriately. Don t worry, this is not really very difficult. First, request a subnet for your tunnel from your PoP via your SixXS homepage. Once approved, you will get a /48 prefix for your own use: 2^80 1.2 heptillion addresses which are yours to assign to every dust particle in your office or home, if you so desire. The way I set it up is to add the first of these addresses to your internal interface on the gateway, by adding the following two lines to the interface s stanza in /etc/network/interfaces; you will need the iproute package installed (which you should be using for everything network-related anyway):

up ip -6 addr add 2001:41e0:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:41e0:ff12::1/64 dev $IFACE

Instead of bringing the interface down and up, just run ip -6 addr add 2001:41e0:ff12::1/64 dev eth0. Note the use of the /64 prefix instead of the /48 that got assigned, leaving only 20 pentillion addresses. Oh no! The reason for this is buried in the specs: basically, /48 is a site prefix, but individual networks should not be larger than /64, which is the prefix length of links in the IPv6 domain. Now is also a good time to enable IPv6 forwarding, e.g. like so:

# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p /etc/sysctl.conf

Obviously, you will also need to change the policy on the ip6tables FORWARD chain. For now, let s just set it to accept. You should later create a proper ruleset, though!

# ip6tables -I FORWARD -j ACCEPT

Bringing IPv6 to your local network The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines. On the gateway, you need to install radvd and simply tell it which prefix to use on which interface. My /etc/radvd looks like this, and I won t explain it:

interface eth0
 
  AdvSendAdvert on;
  prefix 2001:41e0:ff12::/64
   
   ;
 ;

Note again how we advertise a /64 network rather than the /48 we own . You cannot advertise smaller networks if you want automatic configuration to work, and you should not use networks larger than /64 in any case. If 2^64 addresses are not enough for you, I trust you ll be able to figure out how to advertise another of your 65536 /64 prefixes in the /48 subnet to appropriate hosts. Restart radvd and run over to another host to witness how it automagically gets connected to the IPv6 network by scanning /var/log/kern.log and watching the output of ip -6 addr and ip -6 route. Try ping6ing from there! Find the dancing turtle! It should all work. If you don t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and ?wide-dhcpv6-server.

Resolving names Take note of the IPv6 address of each host. There s a way to determine it given the host s MAC address, but this is easier (ipv6calc is also useful). You might want to let your local DNS server know by adding AAAA records in parallel to the existing A records, and possibly even adding PTR entries. If you re serious about IPv6, you can tell SixXS to delegate reverse lookups for the IPv6 addresses to your DNS servers, but you ought to refrain from polluting the DNS namespace. Note that bind9-host provides an improved host tool, which fetches all kinds of information about names, not just the one single information configured as default:

% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.74
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.
% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.

Oh, and if you re really that curious about how IPv6 addresses are computed from MAC addresses, read RFC 2464. Basically, given a prefix 2001:41e0:ff1a:: and a MAC address aa:bb:cc:dd:ee:ff, the resulting IPv6 address is obtained by:

1. inserting ff:fe into the middle of the MAC address to yield aa:bb:cc:ff:fe:dd:ee:ff;
2. flipping the second lowest bit of the first octet to yield a8:bb:cc:ff:fe:dd:ee:ff;
3. removing the odd colons to yield a8bb:ccff:fedd:eeff, the EUI-64;
4. concatenating the prefix and this result to get 2001:41e0:ff1a::a8bb:ccff:fedd:eeff.

If you find your (Windows) IPv6 addresses changing all the time, you might be faced by privacy features .

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Mapping names to laptops Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network. I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:

• override the MAC address of one interface with that of the other, which is going to cause bgi problems in the case when the laptop (accidentally) gets connected to the same network twice;
• add both IPv6 addresses as AAAA records to the laptop s DNS name, which will cause random delays when connecting as the resolver may return the currently inactive address first;
• set up mobile IPv6, e.g. by following this Mobile IPv6 how-to, which would allow accessing the laptop uniformly, no matter where in the world it is. Unfortunately, Debian s support for Mobile IPv6 is severly lacking at time of writing. Also, Yves-Alexis Perez notes that this how-to is horribly outdated and promised to tend to it Real Soon Now .

The second solution works for me for now, but I am interested in the third. In response to this document, Andreas Henriksson has suggested the replace the stateless configuration (radvd) with stateful configuration, using DHCPv6. I have yet to investigate this option. Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on #ipv6/irc.freenode.org for their help over the past few weeks, and all those who fed back comments in response to this document!

This weekend, like past years, I'm off to the Free and Open Source Developers European Meeting in Brussel(s), joining Jeroen and Joost in our friend Geert's car. I recently leared that Belgium is the only seaside country that doesn't have an island. If that information is not worthy of a blog entry then I don't know what is. As you can see I'm certified to attend:

Work. No, not at my workplace, for Debian. I decided to modify the ftp-master webpage a little bit, just adding some css magic (and the ability to conform with that xhtml1.0 strict thing out there). (And to be honest - about 95% of the “work” needed for this was done by Mark Hymers…) But that only happened after something else, which took away most of my time today (and yesterday and the day before). Namely - a nice overview of pending removals. The main purpose of that overview is of course “ftpteam members doing removals can take it for their work”, but i think it may also be nice for users to look there, instead of wading through all the bugreports against ftp.debian.org, which include bugs about totally different topics than removals. (And then I am lazy and want a commandline to paste… :) ) The design for that page was done by Martin Ferrari AKA Tincho, you don’t want to see how my design did look like… :), the idea for it is from Jeroen van Wolffelaar who wrote the first version of it in Perl (it is now implemented in Ruby). The removals html page is regenerated every hour, using the SOAP interface to the BTS, so at least the bugs information should be recent. The other information might have errors in them, don’t trust them too far. It should be right, but then - its only informational.. :) And now: Lets do some of those removals!

For once, Clint blogged on something that I can understand. I don’t buy everything he says, but in the case of DSA, the part where he says “you cannot have a functional and respectable subgroup if it maintains autonomy like that” is a real problem. The leadership problem I mentioned is real. And it can theoretically be solved by undelegating one of the problematic side of this DSA-internal dispute. But which one? Given the unwillingness of Joey to discuss the problems, he makes an easy target… which would leave DSA up to Ryan, James and Phil. But is that a desirable thing? If DSA is perceived as being an “autonomous” group which is not involved in Debian’s main discussions and which is somewhat disconnected from Debian’s day-to-day life, it’s largely due to the behavior of James and Ryan. E-mail communication with them is very difficult as they’ll respond only if they really care about something. And despite the setup of the request tracker, they have barely been able to make proper usage of it… the idea was to use RT tickets to track everything that DSA does but they don’t use it as such. For example, James setup a “wikiadm” group and he never reported anything to the related ticket (#194) (I did it myself once I found out). Also there’s an internal ticket about the replacement of ftp.debian.org (that I created because ftp.d.o ran out of space regularly) and AFAIK Jeroen has been in touch with James to setup that replacement, but nothing got reported to the tracker. Ryan promised me once to put his DSA TODO list in the tracker so that other people can jump in and help out. He never did. So while Joey is definitely a pain for DSA, at least he’s a visible participant of the team and he interacts with the community. James and Ryan are not, they interact only through private channels and do not share their opinions or their vision of Debian.
I believe this is a real problem. On the other hand, most of the interesting changes in the last months are the results of James’s work. But he’s also implicitly blocking addition of new members as long as the leadership problem is not solved. I tried to fill the communication void of the DSA team by various means. I follow everything as closely as I can so that I can report changes on other channels, mailing lists when needed. I made efforts to document stuff on the wiki page, etc. But this is not a long term solution, the communication issue must be fixed within the team. The path ouf of this mess is still not very clear, but something is going to change soon. Not quite sure what though. What would you suggest? And if you were DPL, what would you do? Since private discussions and negotiations lead nowhere, it’s tempting to bring the issue in the public area. In theory, they have no way to escape discussions and they’ll have to communicate their grudges against the other side if they want to have some fair judgment between both parties. Unfortunately, given the habits of James and Ryan, they probably won’t participate in any public discussion and either resign or stay where they are waiting for any decision… Comments welcome. Partagez cet article / Share This

Today I worked on packaging Saxon 8 for Debian. While looking at some of its code I saw the following:

if (System.getProperty("java.vendor").equals("Jeroen Frijters"))
platform = DotNetPlatform.getInstance();

Note: Jeroen Frijters is the author of IKVM.

Copy of a mail I sent to debian-www earlier today. I don't think it warrants posting to -devel-announce, but I post it here to make it visible to people not usually following debian-www. Since I seem to sense an increased stream of offers to help out with packages.d.o coming my way (but maybe that is just wishful thinking ;) I wanted to give a short update on the development of the current code and the status of the infrastructure so that nobody can claim he wanted to help but failed due to lack of information.

• The code in the CVS is seriously lacking in many regards, especially update and CGI speed. It runs pretty stable though and since we excluded robots from using the CGI scripts it seems to run with at least enough speed to keep any big complaints from rising. (If anyone is interested, packages.d.o currently has about 200,000 page hits a day, with a notable decrease – up to 50,000 – during the etch freeze and a similar increase after release)
• packages.d.o is currently run on puccini.d.o, this host is exclusivly used for this purpose. Adminstration is be done by group pkg_maint, current members are Martin 'Joey' Schulze and me.
• The same code is also used to create the page packages.ubuntu.com, see branch ubuntu in CVS. packages.ubuntu.com is run a private server of mine and only administrated by me.
• Everybody with write access to the website has also write access to this part of the CVS. The code run on packages.d.o is updated once a day during the update cron job. Since there is no staging ground for changes, any commits should be made with extreme care...
• Last year Jeroen van Wolffelaar and I started to develop a new version with the goal to make dynamic page generation possible which allows for faster update of information and more flexible presentation. We coordinated our work by using a SVN repository located at svn.wolffelaar.nl.
• This development was stalled several times when he and/or I had no time to actively pursue it.
• In April 2007 I decided to revive the development to get the code in a state ready for deployment. Since I was by then inititated in the wonders of distributed scm, I decided to move the code to yet another repository, namely git (for cloning use git://source.djpig.de/git/packages.git) There is also a ubuntu branch there but it is in a rather sorry state atm regarding site layout.
• I think the new code is currently in a state where it could be safely deployed to packages.d.o but I'm currently waiting for an etch upgrade of the host since the code has grown some dependencies on stuff only available in etch. The next possibility for this to happen is probably during Debconf.
• I don't know yet how to handle the SCM stuff when the code is to be deployed.
• You can try out this new code base at packages.debian.net (Might be slightly out-of-date sometimes since I don't run the cronjob as often as possible to give packages.ubuntu.com more ressources)
• Bug reports and patches against this version are very much welcome, please send them directly to me (but feel free to CC debian-www if you want to have an open discussion on the matter in question).
• Bug reports and patches against the version currently in use should be directed to the BTS as usual.
• If there is interest we can make a little improvised BoF about packages.d.o at Debconf.

It happened again. The linux-2.6 2.6.20-1 release failed for arches which we don't build snapshots for. This means that none of them was ever built in the time after I commited the whole stuff. As this happens over and over again I consider this a real problem now. So the following arches needs new debian-kernel maintainers: alpha, hppa, and mips.